Implementing OSH software: phases, owners and criteria for going live
Implementing OSH software begins when the organisation agrees how it wants to work. Configuring screens is one part of the project. Responsibilities must also be assigned, data reviewed, users prepared and the conditions for starting operations clearly defined before the new system becomes the normal working environment.
A useful plan connects every phase to a deliverable and an acceptance owner. The Explora entry on digitising occupational risk prevention places the change within preventive management. Timelines should reflect scope and available resources. There is no universal implementation period that guarantees a successful result.
Discovery: choose a worthwhile working problem
Collect examples of current work: an assessment, an action, an inspection and a report. Follow their journey between people and applications. Identify delays, duplicated effort and unclear decisions. Distinguish tool limitations from organisational questions that have not yet been resolved and will still need an owner.
Define the initial scope in terms of workflows, sites, roles and languages. State what belongs in later phases. A project beginning with planning and actions needs different criteria from one focused on contractors. The safety lead validates the content while the sponsor confirms priorities and team capacity.
Design and configuration: agree before copying
Map the chosen workflow and identify who prepares, decides, performs and checks each step. Define statuses with a shared meaning. If an activity is marked closed, everyone should understand the evidence and review supporting that status rather than interpreting closure differently in each department.
Then configure structures, permissions, catalogues and communications within the contracted scope. Use the project to remove unused fields and duplication. The Explora entry on change management in OSH helps consider the effects of changing responsibilities or procedures alongside the technology itself.
Data and integrations: establish a reliable foundation
Assign owners to workforce, site and activity data. Agree which source is authoritative and how inconsistencies will be corrected. Do not automate an exchange before understanding what each workflow needs and how frequently its information must be updated. A faster transfer of unclear data can spread the same problem further.
Migration requires its own inventory, mapping and validation work. The article on migrating historical records and evidence explains those tasks. Include an acceptance milestone in the overall plan and define how changes made after the initial load will be handled.
Pilot: test complete workflows, including exceptions
Choose a representative site or team and use cases that traverse the entire process. Include routine work, an overdue activity, reassignment and evidence requiring correction. A pilot containing only perfect records may hide problems that emerge on the first operational day.
- Safety professionals check the technical workflow and its records.
- Users perform tasks without depending continuously on the implementation consultant.
- IT verifies access, data exchanges and recovery against the agreed scope.
- The project lead records issues, decisions and outstanding tests.
- Management or the sponsor confirms that resources and owners are ready.
Separate operational blockers from improvements that can be scheduled later. Each issue needs a priority, owner and resolution condition. Avoid turning an open-ended wish list into a permanent obstacle to launch, while retaining clear acceptance rules for genuinely essential requirements.
Training and launch: prepare each role
Training should reproduce everyday tasks. A supervisor needs to act on an assigned measure; an administrator needs to manage structures and permissions. Ask participants to complete an exercise and provide a short help reference with the appropriate support channel.
Before launch, check data, users, support, communications and transition rules. Record who authorises the start and which conditions have been satisfied. Review the first working cycles afterwards, looking at completed tasks, recurring issues and questions that require configuration or instruction changes.
The project succeeds when work continues reliably
For an illustrative action-tracking project, acceptance should include creation, assignment, implementation and review by actual process users. Created accounts alone do not demonstrate that outcome. The Explora entry on OSH indicators helps define what to monitor after deployment.
Connect the plan to the RFP and demonstration criteria so purchasing commitments remain visible. When considering Sabentis OSH software, request implementation scope with deliverables, owners and acceptance conditions. This gives your team a practical basis for managing the launch.
A practical checklist for the software launch decision
Use this checklist at the launch meeting. Each answer should point to a recorded test or decision, with an owner who can explain the result and any remaining conditions.
- Confirm that critical issues have an agreed definition and none remain unresolved without an explicit decision.
- Ask a user from each role to complete a routine task with their own account, without implementer instructions.
- Confirm who will handle the first deadline, owner change and import error that occur after launch.
- Test the support channel with a fictional enquiry to verify receipt, classification and the person responsible for answering.
- Schedule a review after the first working cycle and define the information needed to decide whether to expand deployment.
Frequently asked questions about implementing OSH software
What is the difference between a demonstration and a pilot?
A demonstration helps assess a proposal before contracting or defining its scope. A pilot tests the intended configuration and procedure for your operation with representative users. Issues must be recorded and resolved against acceptance criteria, rather than merely discussed during a presentation without follow-up.
Can the system launch with unresolved issues?
It depends on their effects on operations, data protection and preventive processes. Distinguish blocking issues from improvements that can wait. Any conditional acceptance must identify the limitation, an adequate operational alternative, an owner and a resolution date; simply marking something “pending” is insufficient.
Does software training replace preventive training?
No. Learning to record an action or consult a case does not provide all the preventive knowledge required for a job. Plan both types of learning around role responsibilities and check their application, retaining the training requirements that apply in Spain or Colombia.
Who should accept the implementation?
Acceptance should bring together the approval of those responsible for the included processes, data and technical operation. The sponsor authorises launch using that evidence. The supplier provides results and resolves issues, but should not unilaterally accept its own work on the company’s behalf.
Legislation and sources consulted
- Spain: Occupational Risk Prevention Act 31/1995: Spain, Articles 16 and 19: integration of prevention and preventive training; technology implementation does not replace those duties.
- Colombia: Decree 1072 of 2015: Colombia, Chapter 2.2.4.6: responsibilities, training and system management. The technology timetable must coexist with the functioning SG-SST.
Sources consulted on 6 October 2026. Checklists and examples are practical implementation proposals.
